home *** CD-ROM | disk | FTP | other *** search
/ Eagles Nest BBS 5 / Eagles_Nest_Mac_Collection_Disc_5.TOAST / Other Non-Macintosh Text / TCPIPV1N11 < prev    next >
Text File  |  1993-10-04  |  9KB  |  228 lines
  1. Aucbvax.5748
  2. fa.tcp-ip
  3. utzoo!decvax!ucbvax!tcp-ip
  4. Tue Jan 12 20:11:06 1982
  5. TCP-IP Digest, Vol 1 #11
  6. >From tcp-ip@brl Tue Jan 12 17:57:58 1982
  7. TCP/IP Digest            Monday, 11 Jan 1981       Volume 1 : Issue 11
  8.  
  9. Today's Topics:
  10.                    Administrivia && The Use of Dot (.)
  11.                    Languages for Implementing TCP-IP?
  12.                   Common Law Copyrights for the Digest?
  13.     Formal Copyrights for the Digest? && TCP Digest as a Public Forum
  14.                         COMSAT Information Update
  15. ----------------------------------------------------------------------
  16.  
  17. From: Mike Muuss <Mike@BRL>
  18. Subject: Administrivia
  19.  
  20. Well, the source of the leak to ComputerWorld has been found, so that
  21. we have some breathing space to mull over the implications (it was an
  22. ArpaNet recipient, so USENET sites need not worry).  It is certainly
  23. clear that anything that goes out in a Digest will reach a large audience,
  24. not all of whom are involved with the ArpaNet (USENET, for example).  At
  25. some time, material WILL fall into "outside" hands.  The question becomes
  26. a choice between:
  27.  
  28.     1)  Being more careful, so that anything said is quotable, or
  29.     2)  Publishing a "restricted rights" notice on the top of the digest
  30.     as a deterent to re-publication.
  31.  
  32. Under no circumstances do I want to restrict the membership or distribution
  33. of this Digest.  I hope that we can get over these political problems, and
  34. get back to discussing technical issues once again.
  35.                     Thoughts?
  36.                       -Mike
  37.  
  38. ------------------------------
  39.  
  40. From: ROODE at SRI-KL (David Roode)
  41. Subject: use of .
  42.  
  43. Why not use ! instead of . for routing in network addresses.
  44. It seems a much wiser choice.
  45.  
  46. ------------------------------
  47.  
  48. From: cak at PURDUE
  49. Subject: Overloading .
  50.  
  51. Many other systems use . as a separator; PhoneNet for CSNET uses it
  52. as in cak.purdue@udel, the Berkeley local network can use it, as in
  53. csvax.cak, PUP uses it, as in clark.WBST@Parc-Maxc, ad nauseum....
  54.  
  55. Chris Kent
  56.  
  57. [ I believe that the CSNET usage of User.Host@Forwarder is the RFC733
  58.   approved addressing format for sites which can't take User@Host@Forwarder.
  59.   The choice of the dot does seem rather unfortunate.  The British have
  60.   adopted RF733 for their mail standard, but selected the percentage symbol
  61.   "%" rather than the dot ".".  -Mike ]
  62.  
  63. ------------------------------
  64.  
  65. Subject: TCP-IP implementations
  66. From: AVRUNIN at USC-ECLB
  67.  
  68. In implementing TCP-IP in various computer systems it would be helpful
  69. to have an implementation to start with.  There seems to be severaly "C"
  70. versions.  I would like to know what other languages have
  71. been used for implementations.  I would especially like to know if anyone
  72. has or is using Fortran 77 for implementation.
  73.  
  74. Thanks
  75.  
  76. Larry Avrunin
  77.  
  78. [ I believe that the Tektronix implementation for the CDC NOS system is
  79.   written in RATFOR (Rational FORTRAN).  -Mike ]
  80.  
  81. ------------------------------
  82.  
  83. From: Walt <Haas at UTAH-20>
  84. Subject: Re:   TCP-IP Digest, Vol 1 #10
  85. To: tcp-ip at BRL
  86.  
  87. Would claiming a common law copyright on this digest stop ComputerWorld
  88. from printing quotes?
  89.  
  90. ------------------------------
  91.  
  92. From: Geoffrey H. Cooper <GEOF at MIT-XX>
  93. Subject: Re:   TCP-IP Digest, Vol 1 #10
  94.  
  95.     If there is really a concern about having TCP-IP entries published
  96. on paper-based media, it would help some to put a copyright notice on
  97. each digest:
  98.     (C) Copyright 1982, DARPA, all rights reserved.  The material
  99.         in this digest may not be copied, in whole or in part, for
  100.         purposes of commercial publication without the written
  101.         permission of the moderator.  Individual sections of the digest
  102.         may contain copyright notices which supercede this notice.
  103. This would at least make editors of computerworld and the like hesitate if
  104. given the entire digest.
  105.                 - geof cooper
  106.  
  107. ------------------------------
  108.  
  109. From: cbosgd!mark at Berkeley
  110. To: ucbvax!tcp-ip@Berkeley
  111. Subject: TCP digest as a public forum
  112.  
  113. I just want to make sure the people on this list are aware that each
  114. TCP digest is fed into USENET on newsgroup fa.tcp-ip.  This is sent to
  115. (currently) about 120 machines across the US and Canada.  (For those
  116. who don't know about USENET, it's a distributed bulletin board system.)
  117. USENET specifically has a policy that anything posted to net and fa
  118. newsgroups is public information that can be redistributed to whoever
  119. wants it.  The point is that if you have anything you consider secret,
  120. it probably shouldn't be mailed to the list.
  121.  
  122. While I am under the impression that this policy is consistent with the
  123. intent of the TCP-IP digest, if I'm wrong, it may be necessary to
  124. remove the USENET feed from the mailing list.
  125.  
  126. It is possible that ComputerWorld got their information from USENET,
  127. but from the wording of the article, they seem to have gotten it from
  128. somewhere on the Arpanet.
  129.  
  130. It is easy to confuse private mail and public mailing lists/newsgroups,
  131. and it seems clear that the quote from the digest was written in a
  132. "I'm talking privately to friends" frame of mind.  Clearly he didn't
  133. intend his words to be printed in ComputerWorld.  But it is important
  134. to remember that anything which is mass-mailed is effectively published.
  135.  
  136.     Mark Horton
  137.  
  138. ------------------------------
  139.  
  140. Return-path: Mills@COMSAT
  141. Mail-from: [29.4.6.2] received at USC-ISIE  5-Jan-82 11:46:01
  142. From: Mills at COMSAT
  143. Subject: IP-TCP Digest info update
  144. cc:   Mills at ISIE
  145. Via:  Usc-Isie; 5 Jan 82 18:28-EDT
  146.  
  147. Mike,
  148.  
  149. Following is an extract of a recent report on the status of our
  150. IP/TCP implementation which may be of interest to your readers.
  151.  
  152. The COMSAT IP/TCP implementation, which was sponsored by DARPA,
  153. was developed over the last three years and used extensively for
  154. testing, evaluation and experimentation with other
  155. implementations. This implementation runs in a sizable number of
  156. PDP11s and LSI-11s with varying configurations and applications.
  157. It consists of a package of MACRO-11 modules structured into
  158. levels corresponding to local-net, IP and TCP levels, with user
  159. interfaces at each level. It is designed to be incorporated
  160. either into a special operating system built for a multi-media
  161. internet workstation (so-called "fuzzball," based on RT-11
  162. emulation) or into the RSX-11 operating system as part of a
  163. package to support the INTELPOST electronic-mail network.
  164.  
  165. The local-net level supports several comunication devices,
  166. including synchronous and asynchronous serial lines, 16-bit
  167. parallel links and 1822 interfaces. Hosts using this package have
  168. been connected to ARPANET IMPs, Satellite IMPs, internet
  169. gateways, port expanders and to the DCNET local network. It
  170. provides optional automatic routing, time synchronization and
  171. error-reporting functions. The IP level conforms to the RFC-791
  172. specification, including fragmentation, reassembly, extended
  173. addressing and options, but currently does not interpret options.
  174. A full set of ICMP features compatible with RFC-792 is available,
  175. including destination-unreachable, timestamp, redirect and
  176. source-quench messages. Support for an IEN-142 compatible time
  177. server and an IEN-109 (as amended) compatible internet gateway
  178. can be included on an optional basis. The internet-gateway
  179. support can be configured to include hierarchically structured
  180. gateways and subnets. Destination-unreachable and source-quench
  181. information is conveyed to the user level via the TCP and
  182. raw-datagram protocol modules.
  183.  
  184. The TCP level conforms to the RFC-793 specification, including
  185. PUSH, URGENT and options, but currently does not interpret
  186. options. Its structure is based on circular buffers for
  187. reassembly and retransmission, with repacketizing on each
  188. retransmission. Retransmission timeouts are dynamically
  189. determined using measured roundtrip delays, as adjusted for
  190. backoff. Data flow into the network is controlled by measured
  191. network bandwidth, as adjusted by source-quench information.
  192. Features are included to avoid excessive packet fragmentation and
  193. retransmission into zero windows. The user interface level
  194. provides error and URGENT notification, as well as a means to set
  195. outgoing IP/TCP options.
  196.  
  197. A raw-datagram interface is available for XNET (IEN-158), UDP
  198. (RFC-768) and similar protocols. It includes internal congestion
  199. and fairness controls, multiple-connection management and
  200. timestamping. A number of user-level protocol modules have been
  201. built and tested with other internet hosts, including user/server
  202. TELNET (RFC-764) user/server FTP (RFC-765), user/server MTP
  203. (RFC-780) and various utility file-transfer, debugging and
  204. control/monitoring protocols.
  205.  
  206. Code sizes and speeds depend greatly on the system configuration
  207. and features selected. A typical 30K-word LSI-11/2 single-user
  208. configuration with all features selected and including the
  209. operating system, device drivers and all buffers and control
  210. blocks, leaves about 16K words for user-level application
  211. programs and protocol modules. A typical 124K-word LSI-11/23
  212. configuration provides the same service to a half-dozen
  213. individually relocated users. Disk-to-disk FTP transfers across a
  214. DMA interprocessor link between LSI-11/23s operate in the range
  215. 20-30 Kbps with 576-octet packets. The 124K-word PDP11/34
  216. INTELPOST adaptation supports two 56-Kbps lines and a number of
  217. lower-speed lines.
  218.  
  219. Further information is available from D. Mills (Mills@ISIE) on
  220. the IP/TCP implementation and D. Jupin (Jupin@ISIE) on the RSX-11
  221. adaptation.
  222.  
  223. Regards,
  224. Dave Mills
  225.  
  226. END OF TCP-IP DIGEST
  227. ********************
  228.